Charging in a communication system

ABSTRACT

A method for charging for services in a communication system comprising a charging entity and at least two connection Support entities for providing resources to support connection in the communication system. the method comprising: detecting initiation of a connection for provision by the connection support entities: generating a charging identity for identifying the connection: determining according to a first stored tariff a first charge for the support of the connection by the first connection support entity: determining according to a second stored tariff a second charge for the support of the connection by the second connection support entity; transmitting a first charging message from the first connection support entity to the charging entity. the message specifying the first charge and including the charging identity; and transmitting a second charging message from the second connection support entity to the charging entity, the message specifying the second charge and including the charging identity.

[0001] This invention relates to charging for services in acommunication system such as a mobile telephony system.

[0002] In a basic communication system a simple communication network isprovided, which can link together two communication terminals so thatthe terminals can communicate with each other in a communication sessionor call. Conventionally, a designated entity in the network uses astored tariff to determine a charge for a call based on the call'sduration. Each terminal user has a charging account with the operator ofthe network. The charge for a call is then allocated to the chargingaccount of the user of the terminal that originated the call. When acall is in progress the network may use the tariff to estimate thecharge due in respect of the call so far. The network may periodicallytransmit that estimated charge to the terminal that originated the call,and the estimated charge may then be displayed by that terminal so thatits user can see the ongoing cost of the call.

[0003] Pre-paid communication accounts are becoming increasinglypopular. Under a prepaid account scheme a user pays in advance forcommunication services. As the user makes use of services the chargesfor those services are deducted from the balance of the user's accountuntil the balance has diminished to zero. Then the network blocks theusage of services by the user until the account has been topped up.Pre-paid services have the advantage that the network operator does notneed to trust the user to pay in arrears for services. However, in orderto successfully implement a pre-paid system the operator's network mustbe able to stop the user using services when the balance of his accountfalls to zero. In the basic communication system described above thiscan be achieved simply by the network estimating the charge for a callwhilst it is in progress, comparing that charge with the remainingbalance of the pre-paid account that is to be charged for the call andterminating the call if the charge exceeds the remaining balance.

[0004] In more complex communication systems, for example communicationsystems according to the UMTS (universal mobile telecommunicationssystem) standard for third generation (3G) communication systems thesystems of more than one operator may be used for carrying a call, andoperators of all of those systems may be able to levy chargesindependently for the services the provide in supporting the call.However, a system of this sort would rely on the possibility of reliablyapplying to the correct account the charges made by a number ofoperators for a single call. Furthermore, if in a system of that sortthe user who is to be charged for the call has a pre-paid account thenetwork would have to be able to track the ongoing charge for a call asit was in progress even though the charges for the call derived from anumber of operators. Otherwise, the call might be allowed to continuewhen its cost exceeded the user's pre-paid balance.

[0005] There is therefore a need to provide for enhanced chargingcapability in communication networks.

[0006] According to a first aspect of the present invention there isprovided a method for charging for services in a communication systemcomprising a charging entity and at least two connection supportentities for providing resources to support a connection in thecommunication system, the method comprising: detecting initiation of aconnection for provision by the connection support entities; generatinga charging identity for identifying the connection; determiningaccording to a first stored tariff a first charge for the support of theconnection by the first connection support entity; determining accordingto a second stored tariff a second charge for the support of theconnection by the second connection support entity; transmitting a firstcharging message from the first connection support entity to thecharging entity, the message specifying the first charge and includingthe charging identity; and transmitting a second charging message fromthe second connection support entity to the charging entity, the messagespecifying the second charge and including the charging identity.

[0007] Preferably at least one of the first and second charges isdetermined based on the duration of the connection. Preferably at leastone of the first and second charges is determined based on the amount ofdata transmitted during the connection. Most preferably the connectionsupports the carrying of data in packet form and at least one of thefirst and second charges is determined based on the number of packetstransmitted during the connection.

[0008] Suitably at least one of the first and second charges is of afixed value.

[0009] Suitably each of the first and second connection support entitieshas a unique identity.

[0010] The step of generating the charging identity is preferablyperformed by one of the first and second connection support entities.There is preferably a step of transmitting the charging identity fromthe said one of the first and second connection support entities to theother of the connection support entities. Preferably each of the firstand second connection support entities maintains a count of the chargingidentities it has generated, and the charging identity is formed bycombining the unique identity of the entity that generates the chargingidentity and the next number in the count maintained by that entity.

[0011] The method preferably comprises the steps of: receiving at thecharging entity the first and second charging messages; and determiningthat the first and second charging messages have the same chargingidentity and in response thereto summing the first and second charges toform a total charge for the connection. Preferably the method comprisesallocating the total charge to a user account.

[0012] The method suitably comprises the steps of transmitting from thefirst connection support entity to the charging entity the uniqueidentity of the first connection support entity; and transmitting fromthe second connection support entity to the charging entity the uniqueidentity of the second connection support entity.

[0013] The method suitably comprises the steps of: transmitting from thefirst connection support entity to the charging entity the first storedtariff; and transmitting from the second connection support entity tothe charging entity the second stored tariff. Preferably, during theconnection the charging entity forms an estimate of the charge for theconnection according to the first and second tariffs

[0014] Preferably the estimate is transmitted to the initiator of theconnection, and/or to a charging entity responsible for and/orassociated with the initiator of the connection.

[0015] Preferably a charging unit of the system compares the saidestimate with a pre-paid balance of an account of the user who initiatedthe connection and if the balance is insufficient terminates theconnection. The balance is suitably deeme; to be insufficient if it doesnot exceed the estimate by a predetermined amount. The predeterminedamount may be zero.

[0016] According to a second aspect of the present invention there isprovided a communication system comprising: at least two connectionsupport entities for providing resources to support a connection in thecommunication system and arranged collectively to detect initiation of aconnection for provision by the connection support entities; generate acharging identity for identifying the connection; and each to determineaccording to a respective stored tariff a respective charge for thesupport of the connection by the respective connection support entityand transmit to a charging entity a respective charging message to acharging entity, the message specifying the respective charge andincluding the charging identity; and a charging entity for receivingcharging messages and summing charges specified by charging messagesthat include the same charging identity to form a total charge for aconnection corresponding to that charging identity and causing the totalcharge to be allocated to a subscriber account.

[0017] The present invention will now be described by way of examplewith reference to the accompanying drawings, in which:

[0018]FIG. 1 is a schematic diagram of a communication network; and

[0019]FIGS. 2 and 3 show communications for charging operations in thenetwork of FIG. 1.

[0020] The present invention will be described by way of example withreference to the architecture of a 3G network. However, it will beunderstood that it can be applied to any other suitable form of network.

[0021]FIG. 1 depicts the architecture of an all-IP (internet protocol)UMTS communication system. Boxes and ellipses in FIG. 1 indicate networkelements, which are annotated by their standard abbreviations. Thenetwork elements are connected by interfaces indicated by lines, whosetypes are indicated by their standard abbreviations next to the lines.Network elements whose abbreviations carry the suffix “*)” in FIG. 1 areduplicated in the figure for ease of layout, but belong to the samelogical element in the UMTS reference model.

[0022] In the system of FIG. 1, items of terminal equipment (TE) 1 cancommunicate with the UMTS network 2 via radio (R) interface 3. By thismeans the TEs can communicate with other TEs that are connected directlyto the UMTS network or are connected to other networks 4 that areconnected to the UMTS network. The TEs can also receive applications andservices from application/service platform 5.

[0023] In the system of FIG. 1 it is anticipated that charging controlinformation for generating charges for separate services provided tosupport a connection or call could be generated from a number ofentities:

[0024] 1. The applications and services unit 5 (SCP or otherwise): forexample to make a charge to a user for the use of a supplementary orvalue-added service (e.g. call forwarding, call transfer orrecommendation of a restaurant local to the user).

[0025] 2. The access network (the SGSN 6 or GGSN 7): for provision tothe user of access for his terminal to the UMTS network.

[0026] 3. The multimedia IP network (4 a): for provision of access tothat network and/or for access to specific data from the network andoptionally for guarantees of quality of service In the network.

[0027] 4. Legacy networks such as legacy mobile communication network 4b and legacy PSTN network 4 c: for provision of access to thosenetworks.

[0028] 5. Core network (CPS—a physical element which includes the CSCFand optionally the MGCF too): for use of the UMTS core network fortransfer of data.

[0029] The present application describes a means to combine chargesprovided from such a plurality of sources and also to permit pre-paidsubscriptions to be supported. The charging means described herein makesuse of charging data records (CDR) which are generated in the entitiesthat levy charges and allow the charging control information to bepassed in a coherent way. There are several forms of CDR, depending onthe unit that generates the CDR. However, all the CDRs include a globalcharging identifier (charging ID) which allows the CDRs that have beengenerated in response to a single communication to be matched up.

[0030] Some specific examples of CDRs will now be described.

[0031] Table 1 shows the structure of a C-CDR, which is the form of CDRgenerated by the UMTS CPS 8. This CDR is generated when there has beenpoint-to-point transaction. The CDR comprises a series of fields each ofwhich has a component type. TABLE 1 C-CDR Component Field TypeDescription Record Type BI CPS transaction type Local Record BIConsecutive record number created by Sequence this node. The number isallocated Number sequentially including all CDR types. Charging ID BIPDP context identifier used to identify this PDP context in differentrecords created by CPS. Record Length BI Length of the record User ID BIServed party LN/MSISDN User IMSI BI Served party IMSI Cause for RecordBI The reason for the release of record Closing from this CPS. RecordSequence BI Partial record sequence number in this Number CPS. Onlypresent in case of partial records. Partial Indicator BI Identify thetype of partial record (last) CPS address BI The IP address of the CPSOriginating NE UIO The address of originating side Address networkelement Connected ID UIT Connected party LN/MSISDN Terminating NE UITThe address of terminating side Address network element Access Time TITime stamp when PDP context activation is created in this CPS. Inintermediate charging this is not updated. Opening time TI Recordopening time. Closing Time TI Record closing time. Duration TI Durationof this record in the CPS. Uplink Data TDI Amount of transferred data(uplink) Volume Downlink Data TDI Amount of transferred data (downlink)Volume QoS TDI Quality of Service required/accepted Shared Charging CIType of shared charging. If not used value is “Normal Charging” SharedCI Amount of fee charged from subscriber Percentage “User ID” ReceivedPulses Pulses received from network

[0032] Table 2 shows the structure of an SE-CDR, which is the form ofCDR generated by the application/services platform 5 for the provisionof supplementary services. This CDR also records the correspondingamount of chargeable signalling usage). TABLE 2 SE-CDR Component FieldType Description Record Type BI CPS transaction type Local Record BIConsecutive record number created by Sequence this node. The number isallocated Number sequentially including all CDR types. Charging ID BIPDP context identifier used to identify this PDP context in differentrecords created by CPS. Record Length BI Length of the record User ID BIServed party LN/MSISDN User IMSI BI Served party IMSI Cause for RecordBI The reason for the release of record Closing from this CPS. RecordSequence BI Partial record sequence number in this Number CPS. Onlypresent in case of partial records. Partial Indicator BI Identify thetype of partial record (last) CPS address BI The IP address of the CPSServed Time SI Service usage time Service Code SI Used service

[0033] The fields in the CDRs are as follows:

[0034] Record Type

[0035] Identifies the type of CDR and the direction (in terms oforigination and termination) of the communication that gave rise to it.Examples of record types are listed in table 3. TABLE 3 Examples ofrecord types Record Type Code Description 01 IP originated transaction(GPRS or other CPS) 02 IP terminated transaction (GPRS or other CPS) 03PSTN originated transaction (Including GSM) 04 PSTN terminatedtransaction (Including GSM) 05 Camel originated transaction 06 Camelterminated transaction 07 FORW (For forwarding subscriber) 08 ROAM (Forroaming subscriber) 09 Service CDR (SE-CDR) 10 For future use 11 Forfuture use

[0036] Local Record Sequence Number

[0037] The consecutive record number of the CDRs created in the item ofnetwork equipment that generated this CDR.

[0038] Charging ID

[0039] The global charging ID. This is created, as described in moredetail below, in for example the SGSN or CPS or another network element.

[0040] Record Length

[0041] Length of the CDR in bytes

[0042] User ID

[0043] Served party identification. The format of the field depends onthe type of transaction.

[0044] User IMSI

[0045] Served party IMSI

[0046] Cause for Record Closing

[0047] The reason for record closing. If intermediate charging occursthis indicates the reason of the intermediate charging.

[0048] Received Pulses

[0049] Pulses received from the network (ISUP).

[0050] Record Sequence Number

[0051] Partial record sequence number. Only present in case of partialrecords.

[0052] Partial Indicator

[0053] Identify the type of partial record (partial, last partial)

[0054] CPS Address

[0055] The IP address of the CPS.

[0056] Originating NE Address

[0057] The address of originating side network element. This depends onthe type of transaction.

[0058] Connected ID

[0059] Connected party identification. This depends on the type oftransaction.

[0060] Terminating NE Address

[0061] The address of terminating side network element. This depends onthe type of transaction.

[0062] Access Time

[0063] Timestamp when the PDP context has been activated. In case ofintermediate charging this remains the same during whole transaction.

[0064] Opening Time

[0065] Timestamp when the record has been opened.

[0066] Closing Time

[0067] Timestamp when the record has been closed.

[0068] Duration

[0069] The duration of the transaction.

[0070] Uplink Data Volume

[0071] Amount of transferred data uplink.

[0072] Downlink Data Volume

[0073] Amount of transferred data downlink.

[0074] QoS

[0075] Quality of service required/accepted

[0076] Served Time

[0077] Timestamp when service has been used

[0078] Service Code

[0079] Identifies which service has been used. Signaling could be one ofthe chargeable services (case by case)

[0080] Shared Charging

[0081] Type of shared charging.

[0082] Shared Percentage

[0083] Amount of fee charged from user identified in field “User ID”

[0084] The component types of the CDRs are listed in table 4. TABLE 4CDR component types Component type Description BI Basic information UIOUser information originating - information relating to the user thatoriginated the connection UIT User information terminating - informationrelating to the user that terminated the connection TI Timeinformation - information relating to the time and temporal duration ofthe connection TDI Transferred data information - information relatingto the amount of data transferred during the connection CI Charginginformation - information relating to the charging structure for theconnection SI Service information - information relating to theservice(s) used in the connection

[0085] Other CDRs may be formed in a like way to those described above.

[0086] The operation of charging using such CDRs will now be described.

[0087] The global charging ID provides a unique identifier for eachconnection/call. Each CDR includes a global charging ID field whichincludes the global charging ID of the call to which the information init relates.

[0088] The first unit to generate a CDR or to begin charging for a callpreferably generates the global charging ID for the call. One means bywhich this may be achieved is for each network unit that can generateglobal charging IDs to have an identity, for example in the form of anidentity number, that is unique in the sense that no other unit that cangenerate CDRs has the same identity. Then each network unit that cangenerate global charging IDs also keeps a count, for example as aninteger, of the global charging IDs that it issues. When the unit needsto form a global charging ID it combines its own identity number withthe latest count number (e.g. by concatenating those numbers together)to produce the global charging ID and increments the count by one. Forexample, if the unique ID of the unit is 934521 and its count of globalcharging IDs it has issued is 324632 then the next global charging ID itwould issue would be 934521324632 and the one after that (followingincrementation of the count) would be 934521324633. The unique ID of theunit could be its network identity or its IP address or could be formedfrom either or both of those. The count is suitably 32 bits (4 bytes)long.

[0089] Alternatively the global charging ID may be generated centrally:a unit requiring a new global charging ID could request it from a globalcharging ID server.

[0090] Once a global charging ID has been generated in relation to acall that same global charging ID is used by all the entities thatgenerate charges for the call, being included as the charging ID fieldof each of their CDRs for the call. To allow this to happen the firstunit to generate a CDR or to begin charging for a call—i.e. the unitthat generated the charging ID or requested it from the server—causesthe charging ID to be made available to the other entities that may needto generate CDRs for the call. This is preferably done by transfer ofthe charging ID over the protocols used between the entities, forexample the SIP and GTP protocols in UMTS. This may require the additionof an element to such protocols as they are presently formed, includingthe protocols that are used for communication with legacy networks suchas GSM networks that may also need to generate CDRs. However, supportfor this feature allows the unit that generates or first acquires thecharging ID pushes it to the other entities that may need to generateCDRs for the call.

[0091]FIG. 2 illustrates an example of the system in operation. In FIG.2, unit 20 is a mobile station or item of user or terminal equipment,unit 21 is the charging generation unit of a GPRS network, unit 22 isthe CPS 8 of a UMTS network, unit 23 is the charging generation unit ofa PSTN network or the MSC of a GSM network, and unit 24 is the SCE ofthe UMTS network.

[0092] When a call is to be made from TE 20 via the GPRS system to aterminal of the PSTN 23 the call first reaches the GPRS system (step30), which recognises that it has no global charging ID for the call andtherefore generates one according to the method described above (step31). In passing the call to the core network of the UMTS system the GPRSsystem passes the global charging ID it has generated for the call (step32). In passing the call to the PSTN the core network of the UMTS systempasses the global charging ID it has received for the call (step 33).When the call is complete the entities that need to generate charges forthe call each generate CDRs that include the global charging ID of thecall. These are sent to a central point, preferably the charging entityof the home network of the user of the TE 20, where that user's accountis homed. In this example that is assumed to be the UMTS network.Therefore, the entities 21 and 23 generate CDRs (steps 34, 35) and sendthem to the unit 22 (steps 36, 37). The unit 22 sends those CDRs when itreceives them to the charging entity 24 (step 38). The unit 22 alsogenerates a CDR itself, which it sends to the charging entity 24. Evenif the CDRs arrive at the charging entity 24 at different times thecharging entity can match them up because they include the same globalcharging ID.

[0093] When the charging entity receives a CDR it checks whether it haspreviously received a CDR having the same global charging ID as thenewly received CDR. If it has not it forms a new transaction on theaccount of the user to whom the newly received CDR indicates a chargeshould be made, the transaction initially having the value indicated inthe CDR. When any more CDRs having the same global charging ID arereceived their value is added to the same transaction. The total valueof the transaction is debited from the user's account. The transactionmay be debited from the user's account as a single item so that thecharges derived from different sources for a single call are transparentto the user. The transaction may be itemised so that the user can seehow the total charge is made up.

[0094] Alternatively, the CPS 22 could collect and match up the CDRs andsend a single totalised indication of the transaction to the SCE 24.

[0095] The elements of the network that generate charges and that modifyor use charging information support the transfer of charging informationelements (CIEs). CIEs describe the basis that is to be used for chargingof a call and the information they carry allows the total or itemisedcharge for a call to be estimated whilst the call is in progress andbefore CDRs have been generated. Information in a CIE has two generalpurposes: providing a user with advice of charge (mobile chargingpart—MCP) and providing network elements with a specification of howcharges are to be levied (network charging part—NCP). Different CIEs maybe used for these purposes, but for simplicity and compatibilitypreferably a unified form of CIE is used.

[0096] Table 4 shows the form of an example CIE. TABLE 4 Form of CIEField description NCP ? MCP ? Tariff currency (ETSI ISUP) - used asdescribed in Yes Yes ES 201 296 Units per time interval - defines howmany currency Yes Yes units are charged per time interval defined in thetime interval field Time interval - defines the time interval used asthe Yes Yes basis for charging Switchover time (ETSI ISUP) - used asdescribed in Yes ES 201 296 Shared charging information - describes thetype of fee Yes sharing to be used Shared charging percentage -describes the percentage Yes that the service provider is willing to payaccording to the shared charging information field Call attempt charge(ETSI ISUP) - used as described in Yes ES 201 296 Call set-up charge(ETSI ISUP) - used as described in Yes ES 201 296 Quality of service -describes the quality of service Yes Global charging ID - indicates theunique reference Yes described above Pre-paid information - indicates apre-paid threshold Yes value for the subscriber, which could benetwork-dependent

[0097] Preferably when a call is set up each of the entities that willmake a charge for the call generates a CIE of this form and transmits itto the charging entity of the user's home network, where thecall-originating user's account is homed (transmission steps 40, 41 and(not shown) transmission from unit 22 to unit 24 in FIG. 2). This allowsthat unit to estimate the itemised and total charges that will be leviedfor the call by all those entities. The CIEs can, as for the CDRs bematched up on the basis of the global charging ID, which all CIEs for asingle call have in common.

[0098] If the user requests advice of charge during a call then CIEs maybe sent to the user's terminal from all the entities that will make acharge for the call. Alternatively, the charging entity for the user'shome network may form a CIE summing the charges from the CIEs from thecharging entities and send that to the user's terminal. The CIE(s) sentto the user's terminal could include only the MCP fields, whereas theCIEs sent to the charging entity should include all the NCP fields.

[0099] Since the charging entity for the user's home network can, usingthe CIEs, estimate the total charges that will be levied for a call theCIEs provide a means whereby prepaid accounts may be supported under acharging structure of the type described herein. If the user whooriginated the call has a pre-paid account then the operator with whomthe user has his account will wish to terminate a call whilst it is inprogress if it would otherwise result in the user's account having noremaining credit.

[0100] As a call progresses the charging entity periodically estimatesthe charge for the call so far using the CIEs received for the call.This may be done, for example, every second or every five seconds,depending on the load on the charging entity. The charging entitycompares that estimated charge with the balance of the account to whichthe call will be charged. The operator causes the call to be ended itthe estimated charge exceeds the balance, or—to take account ofpotential errors in the estimation—if the estimated charge is notgreater than the balance by a predetemined threshold. To do this thecharging entity should have knowledge of or should be able to estimatethe call-dependant factors, such as the duration of the call or theamount of data transferred during the call, that may have an impact onthe charge. These may be transmitted periodically to the entity by atleast one of the entities involved in carrying the call, for exampleunit 22 in FIG. 2. Alternatively, they may be estimated by the chargingentity from a knowledge of the time when the call began (e.g.approximately the time at which the CIEs for the call were received bythe charging entity), the present time, and (if needed) an average datatransmission rate. The duration of the call may be estimated bysubtracting the time. at which the call began from the present time. Theamount of data transmitted may be estimated by multiplying the durationof the call by the expected data rate.

[0101] The principle of shared charging enables operators and/or theterminating user to cooperate to share or distribute the charges for acall. In conventional charging the user responsible for originating thecall bears the full cost of the call. Under a shared charging regime theuser of the terminating part may bear part of the cost, eithervoluntarily or under requirement from an operator. The type of sharedcharging may be indicated by a code according to table 5. Sharedcharging code Description 00 Normal charging - Charges not shared. Usedwhen the user of the terminating part is not to bear any of the cost ofthe call. The originating subscriber is charged for the full cost of thecall. 01 Network access fee - Indicates that the user of the terminatingpart will bear part or all of the network access charge. 02 Transferreddata towards used service - Indicates that the user of the terminatingpart will bear part or all of the cost of transferring data towards aused service. 03 Used service - Indicates that the user of theterminating part will bear part or all of the cost of a used service. 04CallControl and MobilityManagement - Indicates that the user of theterminating part will bear part or all of the charge due to call routingand mobility management (due to the CallProcessing server). 05 Totalcost of transaction excluding other services' fees - Indicates that theuser of the terminating part will bear a proportion of the total chargeof the call excluding the charge for the use ofsupplementary/value-added services. 06 Total cost of transaction -Indicates that the user of the terminating part will bear a proportionof the total charge of the call.

[0102] Other types of shared charging may be used in addition to orinstead of those listed above.

[0103] When a call is set up and shared charging is in use the entitiesthat will generate charges for the call determine whether any of thecharges for the call will be shared, for example by checking their ownnetwork policies and any preferences for the user of the part thatterminates the call. Based on that determination they determine whichshared charging code applies to the call. That shared charging code isincluded in the shared charging information field of the CIE that theygenerate, and the percentage (from 0% to 100%) of the appropriate charge(as indicated by that code) that will be borne by the terminating partyis indicated in the shared charging percentage field. By this means theimpact of shared charging can be taken into account if the chargingentity of the originating party's network needs to estimate the chargefor the connection. Provided the sharing is of services provided by thenetwork that is home to the terminating party that network can alsoestimate the charge that will be due to the terminating party andtherefore support the situation where the terminating party has apre-paid account; otherwise copy CIDs indicating the basis for othercharges due to the terminating party must also be transmitted to theterminating party's charging entity.

[0104] If more than one CIE for a call indicates the same sharedcharging value then they are settled by the charging entity of theoriginating party according to the following priority:

[0105] 1. The order in which they were received by that charging entity.

[0106] 2. Calculating the fee from the original cost. When the remainingpart of the corresponding charge is zero then further shared chargingindications are deemed invalid.

[0107] If more than one CIE for a call indicates a different sharedcharging value then they are settled by the charging entity of theoriginating party according to the following priority:

[0108] 1. Charging types 01 to 04 as indicated above are handled first.

[0109] 2. Charging type 05 as indicated above is handled thereafter.

[0110] 3. Charging type 06 as indicated above is handled thereafter.

[0111]FIG. 3 illustrates an example of shared charging in action. In thescenario illustrated in FIG. 3 a subscriber A of mobile terminal/userequipment (MT/UE) 40 accesses a UMTS MIPT (mobile internet protocoltelephony) network via a GPRS network. Subscriber A has activatedservices which are handled by the SCP 41 of the MIPT network. SCP 41includes the user's charging entity. The user also uses otherinternet-related services from multimedia IP network 44 before theactual call is routed and connected to the PSTN 42 that is itsdestination. The PSTN leads to the service number of the terminatingterminal part (not shown in FIG. 3).

[0112]FIG. 3 illustrates the signalling using CIEs that may happen asthe call is set up. Signals 50, 51 illustrate the transmission of afirst CIE: CIE#1. This CIE indicates the basic tariff to the subscriberof the MT/UE 40 for the call (including tariff currency, units per timeinterval and time interval). CIE#1 is transmitted from the SCP to theCSCF 43 and then the MCP parts of the CIE are passed on to the MT/UE 40.

[0113] As the call progresses network 44 indicates that it will make acharge for the use of services by transmitting CIE#2 to CSCF 43 (signal52). CIE#2 indicates the levying of a one-off charge (in the form of acall set-up charge) for the use of a service. CSCF 43 forwards CIE#2 toSCP 41 (signal 53) so that it can take that CIE into account inestimating the ongoing cost of the call in case the user has a pre-paidsubscription. CSCF 43 also informs the MT/UE 40 of the updated chargingregime (signal 54). It does this either by forwarding the MCPinformation from CIE#2 to the MT/UE so that the MT/UE can add that tothe information on CIE#1 that it has already received, or by summing thecharging indicated by the MCP information of CIE#1 and CIE#2 and sendinga CIE indicating that summed charging to the MT/UE to supersede thepreviously sent information.

[0114] Then PSTN 42 indicates via MGCF 44 (signals 55, 56) that it willmake a charge as indicated in CIE#3. This is a charge part of which willbe shared with the terminating user. CSCF 43 forwards CIE#3 to SCP 41(signal 57) so that it can take that CIE into account in estimating theongoing cost of the call in case the user has a pre-paid subscription.CSCF 43 also informs the MT/UE 40 of the updated charging regime (signal58), either by forwarding the MCP information from CIE#3 or byforwarding a superseding summed CIE.

[0115] Charging information is preferably considered separately indetermining whether, for a pre-paid user, individual services may beaccessed or individual calls maintained.

[0116] In general, the protocols that are used between charge-generatingnetwork elements and between network elements that modify charginginformation should support transfer of the charging ID.

[0117] The present invention has been described with specific referenceto the UMTS and GPRS systems. However, it is not limited to thesesystems.

[0118] The applicant draws attention to the fact that the presentinvention may include any feature or combination of features disclosedherein either implicitly or explicitly or any generalisation thereof,without limitation to the scope of any of the present claims. In view ofthe foregoing description it will be evident to a person skilled in theart that various modifications may be made within the scope of theinvention.

1. A method for charging for services in a communication systemcomprising a charging entity and at least two connection supportentities for providing resources to support a connection in thecommunication system, the method comprising: detecting initiation of aconnection for provision by the connection support entities; generatinga charging identity for identifying the connection; determiningaccording to a first stored tariff a first charge for the support of theconnection by the first connection support entity; determining accordingto a second stored tariff a second charge for the support of theconnection by the second connection support entity; transmitting a firstcharging message from the first connection support entity to thecharging entity, the message specifying the first charge and includingthe charging identity; and transmitting a second charging message fromthe second connection support entity to the charging entity the messagespecifying the second charge and including the charging identity.
 2. Amethod as claimed in claim 1, wherein at least one of the first andsecond charges is determined based on the duration of the connection. 3.A method as claimed in claim 1 or 2, wherein at least one of the firstand second charges is determined based on the amount of data transmittedduring the connection.
 4. A method as claimed in claim 3, wherein theconnection supports the carrying of data in packet form and at least oneof the first and second charges is determined based on the number ofpackets transmitted during the connection.
 5. A method as claimed in anypreceding claim, wherein at least one of the first and second charges isof a fixed value.
 6. A method as claimed in any preceding claim, whereineach of the first and second connection support entities has a uniqueidentity.
 7. A method as claimed in any preceding claim, wherein thestep of generating the charging identity is performed by one of thefirst and second connection support entities.
 8. A method as claimed inclaim 7, comprising the step of transmitting the charging identity fromthe said one of the first and second connection support entities to theother of the connection support entities.
 9. A method as claimed inclaim 7 or 8 as dependant on claim 6, wherein each of the first andsecond connection support entities maintains a count of the chargingidentities it has generated, and the charging identity is formed bycombining the unique identity of the entity that generates the chargingidentity and the next number in the count maintained by that entity. 10.A method as claimed in any preceding claim, comprising the steps of:receiving at the charging entity the first and second charging messages;and determining that the first and second charging messages have thesame charging identity and in response thereto summing the first andsecond charges to form a total charge for the connection.
 11. A methodas claimed in claim 10, comprising allocating the total charge to a useraccount.
 12. A method as claimed in claim 10, comprising dividing thetotal charge into at least two portions and allocating one of thoseportions to a first user account and the second of those portions toanother user account.
 13. A method as claimed in claim 12, wherein thefirst user account is associated with a terminal that initiated theconnection.
 14. A method as claimed in claim 13, wherein the second useraccount is associated with another terminal to which the terminal thatinitiated the connection has been connected by means of the connection.15. A method as claimed in claim 13, wherein the second user account isunassociated with another terminal to which the terminal that initiatedthe connection has been connected by means of the connection.
 16. Amethod as claimed in claim 6 or any of claims 7 to 15 as dependantdirectly or indirectly on claim 6, comprising the steps of: transmittingfrom the first connection support entity to the charging entity theunique identity of the first connection support entity; and transmittingfrom the second connection support entity to the charging entity theunique identity of the second connection support entity.
 17. A method asclaimed in any preceding claim, comprising the steps of: transmittingfrom the first connection support entity to the charging entity thefirst stored tariff; and transmitting from the second connection supportentity to the charging entity the second stored tariff.
 18. A method asclaimed in claim 17, wherein during the connection the charging entityforms an estimate of the charge for the connection according to thefirst and second tariffs
 19. A communication system comprising: at leasttwo connection support entities for providing resources to support aconnection in the communication system and arranged collectively todetect initiation of a connection for provision by the connectionsupport entities; generate a charging identity for identifying theconnection; and each to determine according to a respective storedtariff a respective charge for the support of the connection by therespective connection support entity and transmit to a charging entity arespective charging message to a charging entity, the message specifyingthe respective charge and including the charging identity; and acharging entity for receiving charging messages and summing chargesspecified by charging messages that include the same charging identityto form a total charge for a connection corresponding to that chargingidentity and causing the total charge to be allocated to a subscriberaccount.
 20. A method for charging for services in a communicationsystem capable of supporting communication between at least a first userterminal and a second user terminal, the communication system including:a charging entity for attributing to an account associated with one ofthe terminals a charge for the use of services in supporting thecommunication; and a plurality of communication support entities eachcapable of providing services to support the communication and to whichpayment for the provision of the respective services in supporting thecommunication is attributable; the method comprising: each communicationsupport entity transmitting to the charging entity an indication of arespective charging calculation method; the charging entity receivingand storing each indication of a charging calculation method togetherwith an indication of the entity to which the indication relates;establishing a communication link between the first user terminal andthe second user terminal by means of services provided by a sub-set ofthe communication support entities; and the charging entity performingthe steps of: determining for each of the communication support entitiesof the sub-set a respective amount; attributing to each of thecommunication support entities of the sub-set a payment determined independence on the respective amount; and attributing to an accountassociated with one of the first user terminal and the second userterminal a charge determined in dependence on the sum of the determinedamounts.
 21. A method for charging for services in a communicationsnetwork, comprising: determining a charge for a connection between afirst terminal and a second terminal; dividing the charge into at leasttwo sub-charges; and allocating one of those portions to a first useraccount and the second of those portions to another user account.
 22. Amethod as claimed in claim 21, wherein the first user account isassociated with a terminal that initiated the connection.
 23. A methodas claimed in claim 22, wherein the second user account is associatedwith another terminal to which the terminal that initiated theconnection has been connected by means of the connection.
 24. A methodas claimed in claim 23, wherein the second user account is unassociatedwith another terminal to which the terminal that initiated theconnection has been connected by means of the connection.
 25. A methodfor charging for services in a communication system substantially asherein described with reference to the accompanying drawings.
 26. Acommunication system substantially as herein described with reference tothe accompanying drawings.